summary |
shortlog | log |
commit |
commitdiff |
tree
first ⋅ prev ⋅ next
Nate Graham [Wed, 14 May 2025 01:53:34 +0000 (19:53 -0600)]
[PATCH] Fix ActionTextField RTL
This got broken in
d8cbb0fd050861a0e08fd45192d311b65d2d4dc3, which was
not technically correct; if it worked at the time, it broke since then.
This reverts
d8cbb0fd050861a0e08fd45192d311b65d2d4dc3
BUG: 504091
FIXED-IN: 6.15
Gbp-Pq: Name upstream_5bf798c3_Fix-ActionTextField-RTL.patch
Noah Davis [Mon, 14 Apr 2025 17:54:25 +0000 (13:54 -0400)]
[PATCH] tst_scrolling.qml: don't set default angle delta to verticalStepSize, don't test if smooth scrolling is enabled when testing angle delta moves
While arbitrary angle deltas are allowed, setting the default angle delta size to verticalStepSize is not semantically correct because verticalStepSize is not an angle delta.
We shouldn't make more assumptions about WheelHandler's internal logic than necessary since there is already a way to avoid failing the test when smooth scrolling is enabled.
Gbp-Pq: Name upstream_bf7ead57_tst-scrolling-qml-don-t-set-default-angle-delta-to-verticalStepSize-don-t-test-if-smooth-scrolling-is-enabled-when-testing-angle-delta-moves.patch
Noah Davis [Mon, 14 Apr 2025 17:49:23 +0000 (13:49 -0400)]
[PATCH] WheelHandler: smooth scroll for a greater variety of movement sizes
Duration is based on the duration and movement for 120 angle delta.
Shorten duration for smaller movements, limit duration for big movements.
We don't want fine deltas to feel extra slow and fast scrolling should still feel fast.
Minimum 3 frames for a 60hz display if delta > 2 physical pixels
(start already rendered -> 1/3 rendered -> 2/3 rendered -> end rendered).
Skip animation if <= 2 real frames for low refresh rate screens.
Otherwise, we don't scale the duration based on refresh rate or
device pixel ratio to avoid making the animation unexpectedly
longer or shorter on different screens.
BUG: 484309
Gbp-Pq: Name upstream_fb21ee82_WheelHandler-smooth-scroll-for-a-greater-variety-of-movement-sizes.patch
Arjen Hiemstra [Tue, 8 Apr 2025 09:12:26 +0000 (11:12 +0200)]
[PATCH] controls: Remove redundant states from InlineMessage
States describe changes from a base state. The base state can just be
declared normally, there is no need to declare it as a separate state.
This fixes centering the close button in single-line inline messages,
because the "centered" state was never activated.
Gbp-Pq: Name upstream_bae0957d_controls-Remove-redundant-states-from-InlineMessage.patch
Arjen Hiemstra [Tue, 8 Apr 2025 09:10:47 +0000 (11:10 +0200)]
[PATCH] controls: Improve calculation of InlineMessage implicit height
If the text isn't long enough to wrap into mulitple lines, but we have
many or large actions such that the actions are still put below the
text, the actions and close button would overlap because the close
button is not accounted for. To fix that, always anchor the actions at
the bottom and calculate a more proper implicit height for the entire
inline message that accounts for close button height if it is visible.
Gbp-Pq: Name upstream_2c6cd90f_controls-Improve-calculation-of-InlineMessage-implicit-height.patch
Arjen Hiemstra [Mon, 7 Apr 2025 15:26:11 +0000 (17:26 +0200)]
[PATCH] controls: Fix link activation for text of InlineMessage
Rather than stretching both the label and toolbar across the entire
inline message, use implicit width for both, unless either would become
larger than the InlineMessage width. Most importantly, since the toolbar
only takes space that is not used by the text, this avoids links in the
text not working correctly.
BUG: 500578
Gbp-Pq: Name upstream_82abc769_controls-Fix-link-activation-for-text-of-InlineMessage.patch
Arjen Hiemstra [Mon, 7 Apr 2025 15:21:41 +0000 (17:21 +0200)]
[PATCH] layout: Set implicit width of ToolBarLayout before using its width
Split setting implicit size into setting width and height separately, so
that we if we use width() it will use the implicit width if no width was
set yet. This avoids us hiding all actions because width is 0, only to
then show them again because implicit width (and thus width) is now a
valid value.
Gbp-Pq: Name upstream_81352c22_layout-Set-implicit-width-of-ToolBarLayout-before-using-its-width.patch
Arjen Hiemstra [Mon, 7 Apr 2025 15:15:24 +0000 (17:15 +0200)]
[PATCH] layouts: Always relayout on geometry changes in ToolBarLayout
Otherwise we end up with several corner cases where the implicit width
is the same as width but we still have actions hidden.
Gbp-Pq: Name upstream_e3c6af3b_layouts-Always-relayout-on-geometry-changes-in-ToolBarLayout.patch
Aurélien COUDERC [Tue, 20 May 2025 06:38:42 +0000 (08:38 +0200)]
kf6-kirigami (6.13.0-2) unstable; urgency=medium
[ Aurélien COUDERC ]
* Backport upstream commits:
- Fix activation of links in inline messages. (kde#500578)
- Fix smooth scrolling not behaving correctly for some movement sizes.
(kde#484309)
- Fix password and search fields not handling RTL languages properly.
(kde#504091, kde#503012)
- Fix for screen readers to no longer rather pointlessly announce “LAYERED
PANE ZERO ITEMS” all the time in Kirigami-based apps and System Settings
pages.
[dgit import unpatched kf6-kirigami 6.13.0-2]
Aurélien COUDERC [Tue, 20 May 2025 06:38:42 +0000 (08:38 +0200)]
Import kf6-kirigami_6.13.0-2.debian.tar.xz
[dgit import tarball kf6-kirigami 6.13.0-2 kf6-kirigami_6.13.0-2.debian.tar.xz]
Patrick Franz [Sat, 12 Apr 2025 17:34:19 +0000 (19:34 +0200)]
Import kf6-kirigami_6.13.0.orig.tar.xz
[dgit import orig kf6-kirigami_6.13.0.orig.tar.xz]